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“The go to statement as it stands is just 
too primitive; it is too much an invitation to 
make a mess of one’s program.” 

— Edsgar Dijkstra, 1968 
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Spaghetti Code Sin 


University 


= Anti-Patterns: Hacker 


http://www.hacker-dictionary.com/terms/spaghetti-code 






Spaghetti code 
: Deeply nested n. Code with a complex and tangled control structure, esp. one using many GOTOs, 
conditionals exceptions, or other unstructured. branching constructs. Pejorative. The synonym 


‘kangaroo code’ has been reported, doubtless because such code has many jumps in it. 


e “Switch’ nesting 
e High Cyclomatic Complexity (too many paths through the code) 


= Unstructured code leads to bugs 
e Unstructured code is generally hard to understand, test, and review 
— But, even structured code can be problematic if it is too complex 
e Want to limit complexity within each unit (e.g., subroutine, method) 
— Complex code is difficult to review — you will miss bugs during review 
— Complex code can be difficult or impossible to test 
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a ° Carnegie 
Measuring Complexity Mellon 


University 
= McCabe Cyclomatic Complexity (MCC) iii 
e Measure each module (subroutine, method, ...) 
e Draw acontrol flow graph 
— Graph has an arc for each path through the module 
e MCC is # of “holes” in graph + 1 
— Worst case number of unit tests to cover all paths 
— Might need more tests — it's a guideline 


MCC=5 


Ja 


= Strict Cyclomatic Complexity (SCC) 


e For complex “if” tests, each condition counts 
— “if ( (x == 0) || (y == 0)) ...” 
counts as +2, because need to test x!=0 and y!=0 5 
— MCDC testing requires this type of coverage return 
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Carnegie 


High MCC Results in Tangled Code University 
= Complexity beyond GOTO due to: = 


e Nested conditionals 

e Overly complex lines of code 
e Multiple return points 

e Nested exceptions 

















{=I Cyeteanaiie Harw Gragin 


=e <s: | m™ Applying MCC 
ay: : | e Want maximum MCC to be 10 or 15 
—- Above 30 is highly suspect 


— Above 50 is untestable in practice 
» Too tangled to reasonably test each path 
» Exception for flat switch statements 

—- Above 75 predicts bug farms 

Module with complexity 77. » Each fix breaks something else 
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5 http:/;www.mocabe.com/pdf/mccabe-nist235r.pdf 


Carnegie 
Mellon 
University 


Problem: complex conditionals used to game complexity 
e If (x) { if (y) Cif (Z) {...} }} = MCC of +3 
e If (x &&y && z) {..} > MCC of +1 


— But same number of test cases... 
.. and same complexity 


Solution: SCC (also known as CC2) 
e Every extra conditional Boolean term counts +1 


— if pe _ if ~ { if (z) {...} }} => SCC of +3 
~ if (x &&y && z) {...} > SCC of +3 


ge ip notes on applying pie ta r 
e This is a per-su Ib rout ir le me tri Cn ot whole .c file 


e The 5 ia is to encourage preaving up abhatay code into stele pieces 
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Carnegie 


_ Spaghetti Factor (SF) Metric coe 


SF = SCC + (Globals*5) + (SLOC/20) 

e SCC = Strict Cyclomatic Complexity 

e Globals = # of read/write global variables referenced 

e SLOC = # source lines of code (e.g., C statements) 

e Scoring: 
- 5-10 - This is the sweet spot for most code 
- 15- Dont go above this for most modules 
— 20 - Look closely; possibly refactor 
— 30 - Refactor the design 
— 50 - Untestable; throw the module away and redesign 
— 75 - Unmaintainable; throw the module and its design away; start over 
— 100 - Nightmare; throw it out and re-architect 
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: e Carnegie 
Code Complexity Best Practices Mellon 
m Keep MCC below 10 to 15 

e Even better, keep SCC below 10 to 15 

— Exception: easy to test flat switch statements are OK 

e This enables thorough unit test 
= Additional signs of complexity issues 

e ‘If’ statements nested more than 2 or 3 deep 

e Nested “if” and “switch” statements 

e Excessive “break, “continue, multiple “return” 
= If your module is too complex, it’s time to break it up! 

e Focus on worst offenders & break pieces of logic out into helper functions 

e The point of this is to enable good peer review and good unit test 
= Complexity pitfalls: 

e Creeping complexity over time ... at some point, refactor! 
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T COULD RESTRUCTURE | | EH, SCREW GOOD PRACTICE. 
THE PROGRAM'S FLOW | | HOW BAD CAN IT BE? 


OR USE ONE LITLE goto main-sub3; 
‘GOTO’ INSTEAD. 


gl 


* COMPILE* 





https://xked.com/292/ 
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ee || 
Not thinking about how much pain this is going to cause in the future 





Essential 


Rationalizing Your 


PX wstel ale .eele 





O RLY? @ ThePracticalDev 
https://goo.gl/pyDMHX CC BY-NC 2.0 


